Code Review

The change is well-scoped and the overall approach (converting VariantSummaryDocument → VariantSearchResultDocument and indexing both into the shared site index differentiated by category) is consistent with the codebase's existing patterns.

Bug: Unsafe chained access in converter can crash the indexer process

In VariantSearchResultConverter.java:21:

CuratedVariantGenomicLocationAssociation variantLocation = doc.getVariants().get(0).getCuratedVariantGenomicLocations().get(0);
if (variantLocation == null) {
    continue;
}

If any VariantSummaryDocument has:

• getVariants() returning null → NullPointerException
• getVariants() returning an empty list → IndexOutOfBoundsException
• get(0).getCuratedVariantGenomicLocations() returning null or empty → same

The null check on line 22 only guards against variantLocation itself being null, but the exception would be thrown before reaching that check. Since the catch block in startSingleThread calls System.exit(-1), a single malformed document would kill the entire indexer process mid-run.

Consider guarding the chained access, e.g.:

if (doc.getVariants() == null || doc.getVariants().isEmpty()) continue;
var variant = doc.getVariants().get(0);
if (variant.getCuratedVariantGenomicLocations() == null || variant.getCuratedVariantGenomicLocations().isEmpty()) continue;
CuratedVariantGenomicLocationAssociation variantLocation = variant.getCuratedVariantGenomicLocations().get(0);

Everything else looks correct — the two document types use different primary keys so there's no overwrite risk in the shared index, and the converter logic for extracting genes, consequences, and cross-references is sound.